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Abstract of DE 1 01 1 2409 (A1 ) 

The invention relates to a data management method 
which is characterized in that data are input and 
processed on at least one mobile computer (20) that 
is provided with a software (front end), and data are 
collected and stored on at least one central 
processing unit (40, 50) by means of a software 
(back end system). A data exchange between the at 
least one mobile computer (20) and the at least one 
central processing unit (40, 50) takes place via at 
least one local computer (30) and the software 
(middleware) of the local computer (30) is also used 
for intermediate translation and interface control.; 
The invention is further characterized in that general 
data, accessible to any mobile computer (20), are 
collected and stored on the at least one central 
processing unit (40, 50) and that application-specific 
data that are individual of one or more mobile 
computers (20) are collected and stored on a 
computer (20, 30, 60) by means of an additional 
software (customizer). A data exchange between 
the mobile computer (20) and the computer (20, 30, 
60) takes place in such a manner that the software 
(front end) present on the mobile computer (20) is 
configured in an application-specific manner. 




Data supplied from the esp@cenet database — Worldwide 



© BUNDESREPUBLIK 
DEUTSCHLAND 



© Offenlegungsschrift 
® DE 101 12 409 A 1 



® Int. CI. 7 : 

G 06 F 15/177 



DEUTSCHES 
PATENT- UND 
MARKENAMT 



® Aktenzeichen: 
@ Anmeldetag: 
@ Offenlegungstag: 



101 12 409.0 
13. 3.2001 
19. 9.2002 



0) 

o 

CM 



LU 

Q 



@ Anmelder: 


© Erfinder: 


m-creations GmbH, 55116 Mainz, DE 


Antrag auf Nichtnennung 


© Vertreter: 


@) Fur die Beurteilung der Patentfahigkeit in Betracht 


Winter, M., Dipl.-Chem. Dr.rer.nat, Pat.-Anw., 71364 


zu ziehende Druckschriften: 


Winnenden 


US 58 45 255 A 




WO 99 63 473 A2 



Die folgenden Angaben sind den v 

@ Verfahren und System zur Datenverwaltung 
@ Die vorliegende Erfindung betrifft ein Vefahren zur Da- 
tenverwaltung, wobei Daten auf mindestens einem mit ei- 
ner Software (Frontend) versehenen mobilen Rechner 
(20) eingegeben und bearbeitet werden, Daten auf minde- 
stens einem Zentralrechner (40, 50) mittels einer Software 
(Backendsystem) gesammelt und gespeichert werden, 
wobei iiber mindestens einen lokalen Rechner (30) ein 
Datenaustausch zwischen dem mindestens einen mobi- 
len Rechner (20) und dem mindestens einen Zentralrech- 
ner (40, 50) vorgenommen wird und die Software 
(Middleware) des lokalen Rechners (30) zumindest auch 
zur Zwischenubersetzung und Schnittstellenkontrolle 
dient. ErfindungsgemaS ist vorgesehen, dass auf dem 
mindestens einen Zentralrechner (40, 50) allgemeine, fiir 
jeden mobilen Rechner (20) zugangliche Daten gesam- 
melt und gespeichert werden und dass mittels einer wei- 
teren Software (Customiser) anwendungsspezifische, fiir 
*™ einen oder mehrere mobile Rechner (20) individuelle Da- 
^ ten auf einem Rechner (20, 30, 60) gesammelt und gespei- 
chert werden, wobei ein Datenaustausch zwischen dem 
O) mobilen Rechner (20) und dem Rechner (20, 30, 60) er- 
O folgt, derart, dass die auf dem mobilen Rechner (20) vor- 
^ handene Software (Frontend) anwendungsspezifisch 
konfiguriert wird. 
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Beschreibung 

[0001] Die vorliegende Erfindung betrifft ein Verfahren 
zur Datenverwaltung nach dem Oberbegriff des Anspruchs 
1 sowie ein System zur Datenverwaltung nach dem Oberbe- 
griff des Anspruchs 9. 

[0002] Der Gegenstand der Erfindung betrifft somit mo- 
bile Anwendungslosungen zur Datenverwaltung. Aufgrund 
der mobilen Natur einiger Berufsbilder besteht ein groBer 
Bedarf an derartigen mobilen Anwendungslosungen, bspw. 
fur sogenannte Handheld- oder Westentaschenrechner, die 
eine hochstmogliche Mobilitat gewahrleisten. Erwiinscht 
sind hochmobile Anwendungen, die auf mobilen Kleinstge- 
raten laufen, Gruppenarbeit und Netzwerkfahigkeit sowie 
eine Anbindung an zentrale Datenbestande ermoglichen. 
[0003] Ein besonderer Bedarf besteht zum Beispiel im Zu- 
sammenhang mit der Verwaltung von Patientendaten in ei- 
nem Krankenhaus: Ein Arzt will am Bett seines Patienten 
wahrend des Stationsbesuches eine Diagnose dokumenlie- 
ren. Mit Hilfe einer mobilen Anwendung ladt er sich vorher 
die Patientendaten aus einem zentralen Informationssystem 
auf seinen mobilen Westentaschenrechner, dokumentiert 
einfach und schnell mit fertigen Textbausteinen und spielt 
diese wieder in das Krankenhaus-Dokumentationssystem 
ein. Dort konnen sie in der gewohnten Form weiterverarbei- 
tetwerden. 

[0004] Ein derartiges gattungsgemaBes Verfahren bzw. 
System ist in der WO 99/41682 beschrieben. Das bekannte 
Verfahren bzw. System betrifft ausschlieSlich die Verwal- 
tung von Patientendaten im Krankenhaus. Das bekannte Sy- 
stem besteht im wesentlichen aus mindestens einem mobi- 
len Rechner, einem lokalen Anwendungsrechner und min- 
destens einem Zentralrechner. Der lokale Anwendungsrech- 
ner vermittelt den Datenaustausch zwischen dem mobilen 
Rechner und dem Zentralrechner, bspw. einer Datenbank 
mit Patientendaten und stellt diese Patientendaten sowie 
Formblatter, Eingabemasken u. dgl. zur Eingabe von Patien- 
tendaten zur Verfugung. Somit kann der Arzt am Kranken- 
bett Patientendaten abrufen, diese Datcn aktualisieren bzw. 
neue Daten eingeben und auf dem lokalen Anwendungs- 
rechner speichern. Die neuen Daten werden dann weiterver- 
arbeitet, bspw. in eine auf einem Zentralrechner gespei- 
cherte zentrale Patientcndatei eingelesen oder neu forma- 
tiert, bspw. um die Daten in verschiedenen Datenbanken auf 
verschiedenen Zentralrechnern abzulegen. Die Datenuber- 
tragung und der Datenabgleich zwischen dem mobilen 
Rechner und dem lokalen Anwendungsrechner konnen syn- 
chron, bspw. iiber eine Telefon- oder Funkverbindung oder 
asynchron durch Andocken des mobilen Rechners an ein 
Terminal erfolgen. 

[0005] Problematisch bei diesem Losungsvorschlag ist, 
dass dieses Verfahren bzw. System nur sehr schwer an die 
individuellen Bedurfnisse einzelner Nutzer angepasst wer- 
den kann. Zwar konnen mit diesem System vorgegebene Li- 
sten gepflegt werden, aber grundsatzlich ist eine Anderung 
der auf dem mobilen Rechner ablaufenden Anwendung nur 
durch eine neue Programmversion moglich. Dies schrankt 
auch die Anwendung des bekannten Verfahrens bzw. Sy- 
stems in weiteren Anwendungsbereichen wie Vertrieb, La- 
gerhaltung oder Service ein. Bei alien diesen Einsatzgebie- 
ten muss zur Umsetzung einer moglichst optimalen Losung 
eine Verbindung der mobilen Einheit zu den Daten aus zen- 
tralen Systemen hergestellt und die Arbeit in der Gruppe er- 
moglicht werden. In den verschiedenen Einsatzgebieten be- 
stehen jedoch je nach Art der Aufgabenstellung unterschied- 
liche Anforderungen an sowohl die mobile Komponente als 
auch an die Verbindung zu den zentralen Datenbestanden. 
Alle bisher verfugbaren LSsungen beriicksichtigen ledighch 



die mobile Komponente als 'Einzelplatz", wobei nur ein 
Datenabgleich mit einem einzelnen Rechner moglich ist. 
Eine Anpassung der Einzelplatzversion kann ausschlieBlich 
innerhalb der mobilen Anwendung selbst erfolgen, was zeit- 
5 aufwendig und aufgrund der schlechten Eingabemoglichkeit 
bei mobilen Kleinstgeraten meist umstandlich zu bewerk- 
stelligen ist. 

[0006] Die Aufgabe der vorliegenden Erfindung besteht 
somit darin, das bekannte Verfahren bzw. System derart wei- 
10 ter zu entwickeln, dass es in verschiedenen Einsatzgebieten 
an unterschiedliche Anforderungen der individuellen An- 
wender angepasst werden kann. 

[0007] Damit die Anwendung individuell ausgestaltet 
werden kann, muss eine entsprechende, leicht zu bedie- 

15 nende und fur alle Anwender zentral zu pflegende Anwen- 
dungsanpassung ermoglicht werden. 
[0008] Die Losung besteht in einem Verfahren mit den 
Merkmalen des Anspruchs 1 sowie in einem Verfahren mit 
den Merkmalen des Anspruchs 9. ErfindungsgemaB ist also 

20 ein System vorgesehen, bei dem ein lokaler Rechner bzw. 
dessen Software (Middleware) die Kommunikation zwi- 
schen dem mobilen Rechner und dem Zentralrechner ver- 
mittelt, Daten abgleicht, konvertiert und/oder fonnatiert. 
Der lokale Rechner dient also vorwiegend als Zwischen- 

25 iibersetzer und Schnittstellenkontrolleur. Neben dem loka- 
len Rechner ist ein Zwischenrechner mit einer Anwen- 
dungssoftware (Cuslomiser) vorgesehen, mit der die Soft- 
ware auf de mobilen Rechner an individuelle Bedurfnisse 
angepasst wird. Die zwischen dem zentralen Rechner und 

30 dem mobilen Rechner iiber den lokalen Rechner ausge- 
tauschten Daten sind allgemeiner Natur und nicht individua- 
lisiert. Beispiele sind allgemeine Patientendaten in einer 
Krankenhausdatenbank, allgemeine Daten iiber Lagerbe- 
stande, allgemeine statistische Daten, allgemeine Verwal- 

35 tungs- und Abrechnungsdaten. Die spezielle Anwendungs- 
software auf dem Zwischenrechner (Cuslomiser) liefert in- 
dividualisierte Daten und individuelle Bearbeitungsvorla- 
gen, bspw. anwendungsspezifische Formulare und Daten- 
blatter zum Ausfullen, standardisierte Formulareintrage, au- 

40 tomatisierte Abfrageroutinen, Textbausteine, individuelle 
Daten, Listen und Protokolle, neue Meniistrukturen bzw. 
Anpassung bestehender Menus. Damit konnen die vom 
Zentralrechner stammenden allgemeinen Daten individuell 
angepasst, ausgewertet und genutzt werden. Die Anwen- 

45 dungssoftware kann diese individualisierten Daten auch 
mehreren Nutzern mobiler Rechner mit gleichen Bediirfnis- 
sen (bspw. mehreren Arzten der gleichen Abteilung, mehre- 
ren AuBendienstmitarbeitem etc.) gleichzeilig zur Verfii- 
gung stellen, nachdem die Daten von einem Nutzer ange- 

50 passt worden sind. Es findet also eine zentrale Anpassung 
der Software des mobilen Rechners statt. Die Anwendungs- 
software erlaubt das einfache Gestalten personlicher Pro- 
gramme und verarbeitet neue Daten und Programmelemente 
im Zusammenspiel mit dem Zentralrechner und/oder dem 

55 lokalen Rechner. 

[0009] Die vorliegende Erfindung verfolgt somit einen ge- 
nerischen und modularen Ansatz, d. h. neben der Anbin- 
dung an die zentralen Datenbestande existiert eine separate 
Anwendungssoftware. Mit dieser Software werden typische 

60 "Arbeitsdaten", die haufig gebraucht werden, zentral zusam- 
men gestellt und gepflegt. Diese Daten, aber auch Felder, 
Konfigurationen, Menus, Meniistrukturen usw. werden dann 
auf den mobilen Rechner uberspielt. Diese Individualkonfi- 
guration kann durch Vermittlung eines lokalen Rechners 

65 und seiner Software mit einem oder mehreren Zentralrech- 
nern zusammenarbeiten. Nach der Individualkonfiguration 
ist also jeder berechtigte Nutzer in der Lage, iiber den loka- 
len Rechner und dessen Software allgemeine Daten aus dem 
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Zentralrechner auf den mobilen Rechner zu laden und diese mobile Rechner wiederum kommuniziert mit einem lokalen 

zu bearbeiten. Die bearbeiteten Daten werden ruckgespei- Rechner 30, auf welchem eine weitere Soflwarekompo- 

chert und iiber den lokalen Rechner dem Zentralrechner zur nente, im Folgenden Middleware genannt, installiert ist. 

Verfiigung gestellt. Damit kann jeder individuelle Nutzer Dieser lokale Rechner 30 stellt schliefilich die Verbindung 

die fur seinen mobilen Rechner vorgesehenen Anwendun- 5 mit dem oder den Zentralrechnern 40, 50, her und vermittelt 

gen einfach anpassen, z. B. Listen oder Listeneintrage be- den Datenaustausch zwischcn mobilem Rechner 20 und 

quem pflegen, so dass seinen Anforderungen individuell Zentralrechnern 40, 50. Auf dem oder den Zentralrechnern 

Sorge getragen werden kann. 40, 50 konnen verschiedene Systeme, bspw. Datenbanksy- 

[0010] Die grundlegende Idee der Losung ist es, dem Nut- steme, installiert sein, die in Folgenden zusammenfassend 

zer ein einfaches Gestalten personlicher Programme auf 10 als Backendsysteme bezeichnet werden. Zur Anpassung des 

dem mobilen Gerat in einer Form zu ermoglichen, in der Frontend an individuelle Anforderungen des jeweiligen 

dieses Programm dann die neuen Blemente im Zusammen- Nutzers dient eine spezielle Anwendungskomponente, im 

spiel mit z.B. einer zentralen Unternehmensdatenbank wei- Folgenden Customiser genannt, welche auf einem Zwi- 

terhin verarbeiten kann. schenrechner 60 installiert ist, der mit dem lokalen Rechner 

[0011] Vorteilhafte Weiterbildungen ergeben sich aus den 15 30 kommuniziert. 

Unteranspruchen. Die Anbindung der mobilen Komponen- [0024] Selbstverstandlich konnen Customiser und 

ten kann iiber ein Netzwerk erfolgen, so dass auch das Ar- Middleware auf einem Rechner installiert sein, ebenso wie 

beiten in der Gruppe ermoglicht wird. Beim Abgleich des bspw. Frontend und Customiser oder Frontend und Middle- 

mobilen Systems konnen die Anderungen somit auf alle ge- ware, 

wunschten Endgerate iibertragen werden. Dieser Vorgang 20 

funktioniert netzweit, so dass die Anpassungen zentral vor- Frontend 
genommen werden konnen und anschlieBend an alle Benut- 

zer automatisch verteilt werden. [0025] Das Frontend ist die Benutzerschnittstelle fur den 
[0012] Der Customiser kann auf einem Rechner, bspw. ei- Anwender. Hiermit werden sowohl Daten angezeigt als auch 
nem Server oder auch, insbesondere fur kleinere Anderun- 25 durch den Nutzer manipulierl. Dazu werden verschiedene 
gen, auch auf dem mobilen Gerat installiert sein. Dariiber Masken und Listen zur Verfiigung gestellt. Das Design der 
hinaus konnen Frontend und Middleware oder Frontend und Benutzerschnittstelle ist speziell fur die kleinen Endgerate 
Customiser oder Middleware und Customiser auf demsel- mit meist nur begrenztem Display optimiert. 
ben Rechner, bspw. dem lokalen Rechner, dem Zwischen- [0026] Je nach Anforderung an die MobiHtat und die Da- 
rechner oder auch dem mobilen Rechner installiert sein. 30 tenverfugbarkeit kann das Frontend synchron oder asyn- 
[0013] Die Middleware und der Customiser konnen inklu- chron mil dem Backendsystem abgeglichen werden. Der 
sive der Schnittstellen in der Programmiersprache Java ver- synchrone Abgleich bedeutet, dass der mobile Rechner 20 
wirklicht sein, da diese Programmiersprache aufgrund ihrer fur den Einsatz in einem kabellosen Netzwerk geeignet ist. 
Datenbank-Schnittstellen und ihrer Portability Vorteile in Der Nutzer ist somit standig online iiber den lokalen Rech- 
der Anwendung bietet. 35 ner 30 mit dem oder den Zentralrechnern 40, 50 verbunden, 
[0014] Die Verbindung zwischen dem mobilen Rechner so dass Anderungen sofort in die Middleware und/oder in 
und dem lokalen Rechner kann asynchron, bspw. iiber ein das Backendsystem iibernommen werden. Beim asynchro- 
Einsteckmodul oder synchron durch ein Netzwerk, auch nen Abgleich werden die Daten iiber eine stationare Verbin- 
eine kabellose Verbindung, erfolgen. Die Kommunikation dung mit dem lokalen Rechner 30 abgeglichen. Verandert 
zwischen dem lokalen Rechner und dem Zentralrechner fin- 40 der Nutzer Daten auf dem mobilen Gerat, so werden diese 
det bevorzugt iiber standardisierte oder individuelle Schnitt- Anderungen nach einem erneuten Abgleich in der Middle- 
stellen statt. ware und/oder im Backendsystem wirksam. 
[0015] Vorzugsweise ist der Zwischenrechner nur einem [0027] Die Frontendkomponente lauft generell auf alien 
ausgewahlten Benutzerkreis zuganglich, und der Customi- mobilen Rechnern, wie Mobiltelefonen (bspw. mit UMTS- 
ser enthalt Berechtigungskonzepte und -routinen zur Kon- 45 Standard), Handheldgeraten, Palmtops oder Laptops. Be- 
trolle der Zugangsberechtigung der jeweiligen Nutzer. vorzugt werden zur Zeit sogenannte Handheldgerate (oder 
[0016] Ein Ausfuhrungsbeispiel der vorliegenden Erfin- auch Westentaschenrechner, Personal Digital Assistants 
dung wird im Folgenden anhand der beigefiigten Zeichnun- (PDA) etc.). Der meistverbreitete PDA wird von der Firma 
gen naher erlautert. Es zeigen: Palm™ hergestellt und mit dem Palm Operating System 
[0017] Fig. 1 eine schematische Darstellung eines erfin- so (Palm OS) betrieben. Weitere Palm OS Gerate werden u. a. 
dungsgemafien Systems zur Datenverwaltung; von den Firmen Handspring und TRG hergestellt. Neben 
[0018] Fig. 2 eine schematische Darstellung der Anwen- den Palm OS Geraten kann die Frontendhardware auf dem 
dung des erfindungsgemaBen Systems zur Verwaltung von Betriebssystem WinCE der Firma Microsoft betrieben wer- 
Patientendaten; den. Hier gibt es eine Vielzahl von Herstellern. Zukiinftige 
[0019] Fig. 3 eine schematische Darstellung der Anwen- 55 Entwicklungen in diesem Bereich sind vor allem in der Mi- 
dung des erfindungsgemaBen Systems zur Qualitatskon- gration von handelsiiblichen Handys zu mobilen Kleinst- 
trolle an FertigungsstraBen; computern zu erwarten. 

[0020] Fig. 4 eine schematische Darstellung der Anwen- [0028] Die Verbindung der mobilen Rechner 20 mit dem 

dung des erfindungsgemaBen Systems fur das Paybox-Sy- lokalen Rechner 30 kann auf verschiedene Weisen erfolgen. 

stem (Zahlung per Mobiltelefon); 60 Sollen die mobilen Rechner 20 iiber ein kabelloses Netz- 

[0021] Fig. 5 eine Variante der Anwendung gemaB Fig. 4; werk eingebunden werden, so sind z. B. DECT- oder Blue- 

[0022] Fig. 6 bis 18 beispielhafte Darstellungen des Bild- toothnetze geeignet. Erfolgt der Datenabgleich iiber eine fe- 

schirms eines mobilen Rechners fiir die verschiedenen An- ste Station, so wird diese, bzw. der an die mobile Station an- 

wendungen gemaB den Fig. 1 bis 5. gebundene PC iiber ein Netzwerk mit dem lokalen Rechner 

[0023] Das Gesamtsystem 10 besteht aus mehreren Kom- 65 30 verbunden. Auch eine Verbindung iiber GSM ist mog- 

ponenten und Modulen. Jeder Nutzer kommuniziert mit lich. Ferner ist mit zukunftigen Entwicklungen zu rechnen 

dem System iiber einen mobilen Rechner 20 mittels einer wie z. B. Kombinationen (sog. Clones) aus den heutigen 

Softwarekomponente, im Folgenden Frontend genannt. Der Handys und mobilen Computern. 
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[0029] Das Frontend kann vorzugsweise fur mobile Klein- [0035] Innerhalb der Middleware lauft neben einem hoch- 

computer, bspw. mit den Betriebssystemen PalmOS, Wind- komplexen Programmteil auch eine relationale Datenbank, 

ows CE oder EPOC, verwirklicht werden. Durch die Ver- die ein Ansprechen ihrer Tabellen uber JDBC ermoglicht. In 

wendung einer portablen Programmiersprache, bspw. Java, diese Datenbank werden von den Funktionen der Middle- 

ist es leicht moglich, andere existierende und neue Hard- 5 ware die Daten aus verschiedenen Ubertragungen vom 

ware-Gerate zu unterstutzen. Das Frontend kann uber eine Frontend auf Konsistenz gepriift und zusammengeflihrt. Zu- 

eigens definierte Schnittstelle die durch den Customiser er- satzlich spricht der Customiser iiber Java Beans diese Da- 

zeugten Anwendungsvorgaben (welche Listen wohin, wel- tenbank an, um hier eine Datenbank-unterstiitzte Katalog- 

che Menus sollen welche Funktionen erfullen etc.) in Form pflege zu ermoglichen. Auch die vom Benutzer auf dem mo- 

einer Anwendungsbeschreibung einlesen. Die Anwen- to bilen Rechner 20 gewiinschte Menii-Struktur wird in dieser 

dungsbeschreibung entspricht daher in einem gewissen Datenbank gespeichert. Aufgrund der nutzerspezifisch an- 

Sinne einer AP) (Application Programming Interface). Nach zupassenden Meniistruktur wird die Datenbank direkt iiber 

Einrichtung des Frontends werden iiber dieses die Daten, die JDBC angesprochen. 

von der Middleware geliefert wurden, verarbeitet, modifi- [0036] Die PDA-Komponente der Middleware ermoglicht 

ziert und wieder an die Middleware zuriickgereicht. In der is unter der Verarbeitung der vorher durch den Customiser ein- 

Version fur den lokalen Rechner 30 kann diese Funkdonali- gestellten Daten und Meniistrukturen die Verbindung zu ei- 

tat iiber Java Beans und in der Version fur den mobilen nem Zentraldatenbank-System. Hierzu werden die Daten 

Rechner 20 in einer direkten Form in eigenen Tabellen des des Frontends mit den vom Customiser zur Verfugung ge- 

mobilen Rechners realisiert werden. stellten Daten zusammengesetzt und per synchronem oder 
20 asynchronem Protokoll verarbeitet. Diese Version kann 

Middleware bspw. in einem Basic-Dialekt realisiert sein, da mit der aktu- 
ell verfugbaren Prozessortechnologie keine JVM (Java Vir- 

[0030] Damit das Frontend mit dem jeweils vorhandenen tual Machine, die Laufzeitgrundlage von Java auf einem 

Backendsystem reibungslos kommunizieren kann, wird eine Computer) mit akzeptabler Performance verfugbar ist. 

te Middleware eingesetzt. Die Middleware wird auf 25 

n lokalen Rechner 30 ausgefuhrt, der vorzugsweise je Customiser 
nach Auspragung und GroGe des Gesamtsystems ein han- 

delsiiblicher zentraler Server oder ein per Netzwerk ange- [0037] Je nach Einsatzgebiet und Aufgabenstellung soli 

bundener Personal Computer (PC) sein kann. Betriebssy- das Frontend, also die konkrete Anwendung am mobilen 

stemseitig sind hier alle Losungen moglich, vorzugsweise 30 Rechner 20, an die individuellen Vorgaben und Bediirfnisse 

solche, auf denen die Programmiersprache Java zur Verfu- jedes einzelnen Nutzers angepasst werden. Hierzu dient der 

gung steht. Customiser. Durch ihn wird eine Anpassung der Frontend- 

[0031] Die Kommunikation mit dem oder den Zentral- komponente und damit des gesamten mobilen Systems von 

rechnern 40, SO, also den Backendsystemen, erfolgt entwe- einem zentralen Punkt aus vorgenommen. Der Customiser 

der auf der Basis von standardisierten Schnittstellen oder 35 lauft in der Regel auf einem PC oder einem Server (dies 

auf der Basis von speziell entwickelten Schnittstellenlosun- kann auch der PC oder Server sein, auf dem die Middleware 

gen. In beiden Fallen erfolgt eine Ubersetzung des benotig- installiert ist), der im Vergleich zu mobilen Endgeraten eine 

ten Auszugs aus dem Datenmodell des Backendsystems in wesentlich effizientere Bearbeitung der Daten ermoglicht, 

das Datenmodell des Frontendsystems und umgekehrt. kann aber auch, bei kleineren Anwendungen, auf dem mobi- 

Diese Ubersetzung oder Formatierung wird von der Middle- 40 len Rechner 20 installiert sein. 

ware vorgenommen. [0038] Im Customiser werden die individuellen Daten 

[0032] Zusatzlich hat das Middleware-Programm auch bzw. die individuellen Listen ausgewahlt und bearbeitet, die 

vollstandige Schnittstellen zu dem mobilen Rechner 20 (bei das Frontend auf dem mobilen Rechner 20 zur Verfugung 

einem Palm™ ware dies z. B. eine Erweiterung des soge- stellen soli. Auch eine Anpassung der Menus oder der Me- 

nannten "HotSync'-Programmes). Damit ist gewahrleistet, 45 niistruktur kann hier erfolgen. Nach einem Abgleich der 

dass die Daten, die vom Customizer und von dem oder den Frontendkomponente mit der Middleware und/oder den 

Zentralrechnem 40, 50, also verschiedenen Backendsyste- Backendsystemen stehen die Anderungen den Endbenut- 

men (z. B. SAP) kommen, in geeigneterForm zusammenge- zem zur Verfugung. Vorteilhaft ist in diesem Zusammen- 

stellt werden und in der zusammengestellten Form dem mo- hang insbesondere, dass Listen etc. nicht von einzelnen An- 

bilen Rechner 20 zur Verfugung gestellt werden. 50 wendern gepflegt werden miissen, sondem alien Nutzern 

[0033] Die Middleware kann in mehreren Versionen ver- zentral zur Verfugung gestellt werden, da sie von einem zen- 

wirklicht werden, bspw. je eine fiir den lokalen Rechner 30 tralen Administrator gepflegt werden. In der Regel hat nur 

und/oder Zwischenrechner 60 (z. Bsp. fiir die Betriebssy- ein ausgewahlter Nutzerkreis Zugang zum Customiser. Die- 

steme Linux und Windows) und fiir den mobilen Rechner ser fiihrt die entsprechenden Anderungen durch und macht 

20. Bei letzterer handelt es sich bevorzugt um eine kleinere 55 sie somit alien mobil angeschlossenen Anwendern verfiig- 

Middleware-Komponente, die bspw. auf einem Handheld bar. Die entsprechenden Berechtigungskonzepte sind ein 

lauft. Bestandteil des Programms. 

[0034] Die fur den lokalen Rechner 30 bzw. den Zwi- [0039] Die Daten des Customisers werden in einer dafur 

schenrechner 60 vorgesehene Komponente der Middleware vorgesehenen und leicht erweiterbaren Datenbankstruktur 

weist neben verschiedenen anderen Schnittstellen bspw. 60 gehalten. Zur Neuanlage bzw. zur Anderung von individuel- 

auch BAPI-Schnittstellen zu SAP R/3 in den Versionen 4.x len Vorgaben fiir die mobile Anwendung steht eine entspre- 

der Module mm und IS-H auf. Hierzu wurden entlang der chende Benutzerschnittstelle zur Verfugung, die es dem An- 

Programmierrichtlinien von SAP Business-Objekte kompi- wender ermoglicht, Daten schnell und bequem zu andern 

liert, die uber Java Beans ansprechbar sind. In Richtung des oder anzufiigen. 

Frontends (bspw. PDA der Fa. Palm) wird auch uber Java 65 [0040] Auch der Customiser kann bspw. in einer Version 

eine Verbindungsschnittstelle angesprochen, die sich direkt fiir den Zwischenrechner 60 und/oder lokalen Rechner 20 

in das HotSync-Protokoll des PDA einklinkt und damit die oder in einer Version fiir den mobilen Rechner 20 zur Verfii- 

Synchronisation zum Frontend ermoglicht. gung gestellt werden. 
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[0041] Die Version fur den Zwischenrechner 60 bzw. den lokale Rechner 30 eine Verbindung zu dem oder den Zen- 

lokalen Rechner 30 kann ebenfalls in Java realisiert sein. tralrechnem 40, 50, also zum Backendsystem her, vorzugs- 

Der Customiser iibersetzt eine benutzerfreundliche Oberfla- weise iiber ein Netzwerk. AnschlieBend werden die angefor- 

che zum Beispiel mit Hilfe von Clickboxen, geschrieben mit derten Daten aus dem Backendsystem geladen bzw. gean- 

den Java Swing-Bibliotheken, in eine Struktur von Textbau- 5 derte Daten in das Backendsystem zuruckgeschrieben. Die 

steinen, Listen und Menus, die beim nachsten Synchronisa- Middleware sorgt auch fur die Verarbeitung eines Abgleichs 

tionsbefehl auf dem mobilen Rechner 20 sichtbar werden. mit den Daten des Customiser. 

Um die gleichzeitige Unterstiitzung mehrerer mobiler Rech- [0046] Auf dem mobilen Gerat konnen die Daten dann mit 
ner 20 zu gewahrleisten, wird die Ablage der vom Customi- dem Frontend vor Ort, also z. B. am Krankenbett oder beim 
ser zur Verfiigung gestellten Daten in einer eigenen Daten- 10 Kunden, bearbeitet werden, es konnen Dokumentationen er- 
bank sichergestellt. Notwendige neue Tabellen werden hier stellt, Kalkukationen durchgefiihrt oder Anfragen ausge- 
iiber JDBC erstellt, ansonsten iiber die generierten Beans fuhrt werden. Die so bearbeiteten Daten werden dann iiber 
angesprochen. Diese Datenbankinhalte werden dann durch die Middleware zwischenformatiert und zuriick auf den oder 
ein Funktionsset im Customiser, das die Textbausteinen und die Zentralrechner 40, 50, bspw. eine eigene Datenbank oder 
Meniistrukturen ausliest, fiir das Frontend des mobilen is eine Zentraldatenbank (z. B. SAP) ubertragen. 
Rechners 20 umgesetzt, wobei vorher eine Konsistenzprii- [0047] Im Folgenden sollen verschiedene Anwendungs- 
fung auf die Datenstrukturen des lokalen Rechners 30 bzw. beispiele des erfindungsgemaBen Systems bzw. Verfahrens 
der Middleware erfolgt. Bei der Umsetzung auf mehrere beschrieben werden. 
mobile Rechner 20 wird jeweils dieses Funktionsset ange- 
sprochen, das dann die fur den entsprechenden mobilen 20 1 . Verwaltung von Patientendaten (vgl. Fig. 2, Fig. 6 bis 14) 
Rechner 20 gewu'nschte Listen-, Textbaustein- und Menii- 
strukturen iibersetzt und installiert. [0048] Die Funktion des Customisers fiir diese Anwen- 
[0042] Die kleinere Version des Customisers fiir den mo- dung lasst sich wie folgt beschreiben: Jede Fachrichtung er- 
bilen Rechner 20, insbesonderen einen PDA, unterstiitzt bringt verschiedene Leistungen und muss unterschiedliche 
vorzugs weise keine Definition von Menustrukturen, son- 25 Diagnosen steUen. Im Customiser werden die fur die jewei- 
dem nur die Definierbarkeit von Listen und Textbausteinen. lige Abteilung relevanten Diagnosen, Medikamente und 
Sie ist in dem oben genannten Basic-Dialekt verwirklicht, Leistungen in Form von Listen erstellt. Des weiteren konnen 
ansonsten strukturell der graBeren Version des Customiser neue Listen zur Speicberung von Textbausteinen fiir z. B. 
ahnlich, wenn auch sehr vereinfacht. Arztbriefe, Stationslisten oder Telefonnummern erstellt 
30 werden, aber auch Listen mit den fur die Anwender haufig- 
Backendsy sterne sten ICDIO-Verschliisselungscodes und OPS zur automati- 
schen Verschlilsselung von Diagnosen und Leistungen di- 
[0043] Als Backendsysteme kommen verschiedene zen- rekt auf dem mobilen Rechner 20. Dies erfolgt im Normal- 
trale Datenhaltungssysteme in Frage. Dazu gehoren u. a. fall lediglich auf dem lokalen Rechner 30, bspw. einem Ab- 
Krankenhausinformationssysteme (z. B. SAP R/3 mit den 35 teilungsserver. Nach einem Abgleich des mobilen Rechners 
Modulen IS-II und IS-H*med), Enterprise-Ressource-Plan- 20 mit dem lokalen Rechner 30 erhalt jeder das System nut- 
ning (ERP) Systeme, Vertriebsinformationssysteme und zende Arzt automatisch die aktuelle Fassung der Listen und 
Customer-Relationship-Management (CRM) Systeme. Die Textbausteine. 

Anbindung des lokalen Rechners 30 zu den Zentralrechnem [0049] Vor dem Patientenbesuch gibt der Arzt (bei einem 
40, 50 bzw. den Backendsystemen erfolgt vorzugsweise 40 neu aufgenommenen Patienten) die relevanten Patientenda- 
uber ein Netzwerk. Der Datcnaustausch erfolgt entweder ten in ein Formular ein (vgl. Fig. 6), welches vom Customi- 
iiber eine Standardschnittstelle oder eine speziell erstellte ser abteilungsspezifisch zur Verfugung gestellt wird. An- 
Kommunikationssoftware. dernfalls gleicht der Arzt (z. B. asynchron) auf seinem mo- 
[0044] Das erfindungsgemaBe Verfahren kann wie folgt bilen Rechner 20 den fur ihn relevanten Patientendatenbe- 
durchgefuhrt werden: Zunachst legitimiert sich der Nutzer 45 stand ab (vgl. Fig. 7, 8). Damit stehen ihm die aktuellen Pa- 
an dem jeweiligen mobilen Rechner 20 mit Benutzername tientendaten zur Verfugung. Im Laufe des Patientenbesuchs 
und Kennwort. Bei erfolgreicher Anmeldung erhalt er nach erfasst er z. B. Diagnose- und Leistungsdaten (vgl. Fig. 9) 
einem Abgleich mit der Middleware des lokalen Rechners und fiigt Anordnungen ein. Dazu stellt ihm der Customiser 
30 die aktuell verfugbare Information aus dem zentralen Da- z. B. eine Liste der moglichen bzw. in der entsprechenden 
tenbestand des Backendsystems (z. B. Kundendaten) sowie 50 Fachrichtung haufigsten Diagnosen (vgl. Fig. 10, 11) und 
aus dem Customiser (z. B. neue Vorgabetabellen und Vorla- Medikamente (Fig. 12, 13, bspw. die gangigsten Analge- 
gen). Die Informationen werden dem Anwender in Listen- tika) sowie ein auf seine Abteilung angepasstes Set an Text- 
form oder in Form von Auswahlfeldern zur Verfugung ge- bausteinen und weiteren Listen zur Verfugung. Der Arzt 
stellt. Suchfunktionen iiber den Datenbestand oder iiber ein- braucht also die einzelnen Positionen nicht mehr von Hand 
zelne Listen stehen ebenso zur Verfugung. Zur Manipula- 55 in den mobilen Rechner 20 einzugeben, sondern es geniigt 
tion oderNeueingabe von Daten stehen dem Anwender ver- ein einf aches Antippen einer Position in einer Liste. Nach 
schiedene Werkzeuge, bspw. Auswahllisten, vordefinierte erfolgtem Patientenbesuch fuhrt er wiederum einen Ab- 
Textbausteine, Ja-Nein-Felder und die Eingabe von freiem gleich durch (vgl. Fig, 14). Die neuen Daten sind damit zur 
Text, zur Verfugung. Nach erfolgten Anderungen oder Neu- weiteren Bearbeitung im oder in den Zentralrechnem 40, 
eingaben wird das Frontend wiederum mit dem Backendsy- 60 bspw. im Krankenhausinformationssystem, abgelegt. 
stem abgeglichen, so dass die zentral gehaltenen Daten wie- [0050] Beim ersten Abgleich werden vom lokalen Rech- 
der auf den aktuell gultigen Stand gebracht werden. ner 30 zunachst Daten vom mobilen Rechner 20 bzw. vom 
[0045] Will ein Anwender einen Abgleich der Daten des Frontend angefordert. Die Middleware uberpruft die Legiti- 
Frontend mit dem Backendsystem durchfiihren, wird zu- mation des Arztes und stellt die Verbindung zum Zentral- 
nachst eine Netzwerkverbindung zwischen dem mobilen 65 rechner 40, 50, bspw. zum Krankenhausinformationssystem 
Rechner 20 und dem lokalen Rechner 30 hergestellt. Dort (KIS) her, um die Daten (z. B. Patientendaten) an den mobi- 
wird dann die Anfrage bearbeitet. Sollen Daten aus dem len Rechner 20 bzw. das Frontend zu ubertragen. Die Ver- 
Backendsystem angezeigt oder geandert werden, stellt der bindung zum KIS wird z. B. iiber eine standardisierte HL7- 
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Schnittstelle hergestellt. Nach dem Patientenbesuch des 
Arztes mit z. B. Dokumentationen oder Laboranforderun- 
gen auf dem mobilen Rechner 20 bzw. Frontend erfolgt ein 
erneuter Abgleich der Daten des mobilen Rechners 20 in 
Richtung zum KIS uber den Iokalen Rechner 20 bzw. die 5 
Middleware. Sollen neue, individuell angepasste Listen 
(z. B. fachrichtungsspezifische Diagnosen) oder Anwen- 
dungsdaten auf den mobilen Rechner 20 bzw. das Frontend 
eingespielt werden, erfolgt uber die Middleware ein Ab- 
gleich mit den Daten des Customisers. to 

2. Kontrolle von FertigungsstraBen (Fig. 3) 

[0051] Entlang einer Fertigungsstrafie 80, bspw. in der 
Automobilproduktion, sind an einzelnen Fertigungsetappen is 
80a, 80b, 80c Qualitatskontrollen eingerichtet. Jeder Kon- 
trollpunkt ist mit einem mobilen Rechner 20 ausgeriistet, 
welcher iiber einen eigenen Iokalen Rechner und Customi- 
ser mit spezilischen Daten (Tabellen, Listen etc.) fiir die vor- 
gegebene Qualitatskontrolle versorgt wird. Selbstverstand- 20 
lich konnen die einzelnen Iokalen Rechner 30 und/oder Cus- 
tomiser auf einem gemeinsamen Rechner, bspw. einem Ser- 
ver, abgelegt sein. Jeder Nutzer an jedem Kontrollpunkt gibt 
fiir jedes kontrollierte Produkt die entsprechenden Daten in 
den mobilen Rechner ein bzw. fiillt die vom jeweiligen Cus- 25 
tomiser vorgegebenen Formulare aus. Die Daten werden 
iiber den oder die Iokalen Rechner 30 zu einem Zentralrech- 
ner 50 gesendet, welcher die Daten fur jedes Produkt zusam- 
menfiihrt und auswertet. Der lokale Rechner 30 oder der 
Zentralrechner 50 liefern auch fiir jedes Produkt am Ende 30 
en Qualitatsbericht mit einem auf- 
;n Fehlerprotokoll, d. h. den jeweiligen, an den ei- 
nen Kontrollpunkten ermittelten Fehlermeldungen, der am 
Ende der Fertigungsstrafie ausgedruckt wird. 



3. AuBendienst (Fig. 1) 



5. Bezahlen von Lieferdiensten mit Paybox am Beispiel ei- 
nes Pizza-Service (Fig. 5, Fig. 15 bis 18) 

[0054] Hier ist der Bote des Lieferdienstes der Nutzer des 
mobilen Rechners 20. Uber den Customiser wird dem mobi- 
len Rechner die Speise- und Getrankekarte des Lieferdien- 
stes samt Preisen mittels Textbausteinen zur Verfiigung ge- 
stellt. Das Frontend enthalt ein Programm zur Ermittlung 
des Rechnungsbetrages sowie die Middleware zur Herstel- 
lung der Telefonverbindung mit dem Paybox-Zentralrech- 
ner 40. Zur Bezahlung des Rechnungsbetrages tippt der 
Bote die bestellten Speisen im mobilen Rechner an (Fig. 15, 

16) . Das Frontend ermittelt den Rechnungsbetrag (vgl. Fig. 

17) , nimmt Verbindung mit dem Paybox-Zentralrechner auf 
(vgl. Fig. 18) und iibermittelt die Zahlungsdaten des Kun- 
den. Dann erfolgt wieder der Riickruf vom Zentralrechner 
40 zum Mobiltelefon des Kunden zur Abbuchungsbestati- 
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[0052] Mit dem erfmdungsgemaBen System bzw. Verfah- 
ren konnen AuBendienstmitarbeiter mit dem mobilen Rech- 
ner 20 bspw. Lagerbestande abfragen oder Informationen zu 40 
Angeboten und Konditionen einholen undBestellungen auf- 
geben. Je nach Aufgabengebiet liefert der Customiser bspw. 
Antworten zu FAQs der Kunden, automatisierte Lagerbe- 
standsabfragen, wobei die am haufigsten gefragten Produkte 
zuerst gelistet werden, Textbausteine fiir haufige Abfragen 45 
am Zentralrechner oder haufige Bestellungen, etc. Das erfin- 
dungsgemaBe System kann hier also bspw. als Servicesy- 
stem, CRM-Modul (customer relationship management) 
oder als mobiles Bestell- bzw. Kaufsystem (Sales-System) 
dienen. 50 

4. Bezahlen von Taxifahrten mit dem Paybox-System (Fig. 
4) 

[0053] In diesem Fall ist der Taxifahrer der Nutzer des 55 
mobilen Rechners 20, der gleichzeitig als Zwischenrechner 
60 dient, weil der Customiser im mobilen Rechner integriert 
ist. Der Customiser stellt die individuellen Daten des Taxis 
bzw. Taxifahrers zur Verfiigung, wahrend das Frontend den 
Rechnungsbetrag ermittelt und bspw. uber ein GSM-Modul 60 
die Telefonverbindung zum Iokalen Rechner 30 herstellt. 
Der lokale Rechner 30 wiederum vermittelt zwischen den 
verschiedenen Frontends einzelner mobiler Rechner 20 
(z. Bsp. Verschiedener Taxiunternehmen) und stellt die Te- 
lefonverbindung zum Paybox-Zentralrechner her, der hier 65 
als Zentralrechner 40 fungiert. Dann kann der Riickruf auf 
das Mobiltelefon des Fahrgastes erfolgen, mit dem dieser 
die Zahlung bestatigt. 



1 . Verfahren zur Datenverwaltung, wobei 

Daten auf mindestens einem mit einer Software (Fron- 
tend) versehenen mobilen Rechner (20) eingegeben 
und bearbeitet werden, 

Daten auf mindestens einem Zentralrechner (40, 50) 
mittels einer Software (Backendsystem) gesammelt 
und gespeichert werden, 

wobei iiber mindestens einen Iokalen Rechner (30) ein 
Datenaustausch zwischen dem mindestens einen mobi- 
len Rechner (20) und dem mindestens einen Zentral- 
rechner (40, 50) vorgenommen wird und die Software 
(Middleware) des Iokalen Rechners (30) zumindest 
auch zur Zwischeniibersetzung und Schnittstellenkon- 
trolle dient, 

dadurch gekennzeichnet, dass 
auf dem mindestens einen Zentralrechner (40, 50) all- 
gemeine, fiir jeden mobilen Rechner (20) zugangliche 
Daten gesammelt und gespeichert werden, 
und dass mittels einer weiteren Software (Customiser) 
anwendungsspezifische, fiir einen oder mehrere mobile 
Rechner (20) individuelle Daten auf einem Rechner 
(20, 30, 60) gesammelt und gespeichert werden, 
wobei ein Datenaustausch zwischen dem mobilen 
Rechner (20) und dem Rechner (20, 30, 60) erfolgt, 
derart, dass die auf dem mobilen Rechner (20) vorhan- 
dene Software (Frontend) anwendungsspezifisch konfi- 
guriert wird. 

2. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dass der Datenaustausch zwischen dem mobilen 
Rechner (20) und dem Rechner (20, 30, 60) iiber die 
Software (Middleware) des Iokalen Rechners (30) er- 
folgt. 

3. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass die weitere Soft- 
ware (Customiser) auf einem separaten Zwischenrech- 
ner (60) gespeichert wird. 

4. Verfahren nach einem der Anspruche 1 und 2, da- 
durch gekennzeichnet, dass die weitere Software (Cus- 
tomiser) auf dem Iokalen Rechner (30) gespeichert 

5. Verfahren nach einem der Anspruche 1 und 2, da- 
durch gekennzeichnet, dass die weitere Software (Cus- 
tomiser) auf dem mobilen Rechner (20) gespeichert 
wird. 

6. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass Frontend und Cus- 
tomiser oder Frontend und Middleware oder Customi- 
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ser und Middleware auf demselben Rechner gespei- 
chert werden. 

7. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass die weitere Soft- 
ware (Customiser) mit mindestens einem Berechti- 5 
gungskonzept zur Zugangskontrolle versehen wird. 

8. Verfahren nach einem der vorhergehenden Anspru- 
che, dadurch gekennzeichnet, dass der mindestens eine 
mobile Rechner (20) iiber ein Netzwerk an den minde- 
stens einen lokalen Rechner (30) und/oder den minde- 10 
stens einen Zwischenrechner (60) und oder den Zen- 
tralrechner (40, 50) angebunden wird. 

9. System zur Datenverwaltung mit 

mindestens einem mit einer Software (Frontend) verse- 
henen mobilen Rechner (20) zur Eingabe und Speiche- 15 
rung von Daten, 

mindestens einem Zentralrechner (40, 50) mit einer 
Software (Backendsystem) zum Sammeln und zur 
Speicherung von Daten, 

mindestens einen lokalen Rechner (30) zum Datenaus- 20 
tausch zwischen dem mindestens einen mobilen Rech- 
ner (20) und dem mindestens einen Zentralrechner (40, 
50), wobei die Software (Middleware) des lokalen 
Rechners (30) zumindest auch zur Zwischeniiberset- 
zung und Schnittstellenkontrolle dient, 2S 
dadurch gekennzeichnet, dass 

eine weitere Software (Customiser) vorgesehen ist, mit 
der anwendungsspezifische, fur einen oder mehrere 
mobile Rechner (20) individuelle Daten auf einem 
Rechner (20, 30, 60) gesammelt und gespeichert wer- 30 
den konnen, 

wobei ein Datenaustausch zwischen dem mobilen 
Rechner (20) und dem Rechner (20, 30, 60) erfolgt, 
derart, dass die auf dem mobilen Rechner (20) vorhan- 
dene Software (Frontend) anwendungsspezifisch konfi- 35 

10. System nach Anspruch 9, dadurch gekennzeichnet, 
dass ein Zwischenrechner (60) vorgesehen ist, auf dem 
die weitere Software (Customiser) gespeichert ist. 

11. System nach einem der Anspruche 9 und 10, da- 40 
durch gekennzeichnet, dass Frontend und Customiser 
oder Frontend und Middleware oder Customiser und 
Middleware auf demselben Rechner gespeichert sind. 

12. System nach einem der Anspruche 9 bis 11, da- 
durch gekennzeichnet, dass die weitere Software (Cus- 45 
tomiser) mit mindestens einem Berechtigungskonzept 
zur Zugangskontrolle versehen ist. 

13. System nach einem der Anspruche 9 bis 12, da- 
durch gekennzeichnet, dass der mindestens eine mobile 
Rechner (20) iiber ein Netzwerk an den mindestens ei- 50 
nen lokalen Rechner (30) und/oder den mindestens ei- 
nen Zwischenrechner (60) und oder den Zentralrechner 
(40, 50) angebunden ist. 

14. System nach einem der Anspruche 9 bis 13, da- 
durch gekennzeichnet, dass Frontend und/oder Middle- 55 
ware und/oder Customiser in der Programmiersprache 
Java realisiert sind. 

15. Verwendung des Verfahrens nach einem der An- 
spruche 1 bis 8 und/oder des Systems nach einem der 
Anspruche 9 bis 14 zur Verwaltung von Patientendaten 60 
in einem Krankenhaus. 

16. Verwendung des Verfahrens nach einem der An- 
spruche 1 bis 8 und/oder des Systems nach einem der 
Anspruche 9 bis 14 fur den Zahlungsverkehr mittels 
Paybox-System. 65 

17. Verwendung des Verfahrens nach einem der An- 
spruche 1 bis 8 und/oder des Systems nach einem der 
Anspruche 9 bis 14 zur Verwaltung von Lager- und Be- 
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stelldaten. 

18. Verwendung des Verfahrens nach einem der An- 
spriiche 1 bis 8 und/oder des Systems nach einem der 
Anspruche 9 bis 14 zur Qualitatskontrolle in der Pro- 
duktion, insbesondere an FertigungsstraBen. 

19. Verwendung des Verfahrens nach einem der An- 
spriiche 1 bis 8 und/oder des Systems nach einem der 
Anspruche 9 bis 14 als Kaufsystem (Sales-System)-, 
CRM- und/oder Servicesystem. 
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